Computer platform firmware is used during initialization of computer systems to verify system integrity and configuration. It also generally provides the basic low-level interface between hardware and software components of those computer systems, enabling specific hardware functions to be implemented via execution of higher-level software instructions contained in computer programs that run on the computer systems. In many computers, a primary portion of this firmware is known as the Basic Input/Output System (BIOS) code of a computer system. The BIOS code comprises a set of permanently recorded (or semi-permanently recorded in the case of systems that use flash BIOS) software routines that provides the system with its fundamental operational characteristics, including instructions telling the computer how to test itself when it is turned on, and how to determine the configurations for various built-in components and add-on peripherals.
In a typical PC architecture, the BIOS is generally defined as the firmware that runs between the processor reset and the first instruction of the Operating System (OS) loader. This corresponds to the startup operations performed during a cold boot or in response to a system reset. At the start of a cold boot, very little of the system beyond the processor and firmware is actually initialized. It is up to the code in the firmware to initialize the system to the point that an operating system loaded off of media, such as a hard disk, can take over.
Firmware code is commonly stored in a “monolithic” form comprising a single set of code that is provided by a platform manufacturer or a BIOS vendor such as Phoenix or AMI. Various portions of the single set of code are used to initialize different system components, while other portions are used for run-time (i.e., post-boot) operations. In other situations, a monolithic BIOS may be extended using one or more “Option ROMs” (Read Only Memory) that are contained on one or more periphery device cards. For example, SCSI device driver cards and video cards often include an option ROM that contains BIOS code corresponding to services provided by these cards. Typically, firmware in option ROMs is loaded after the firmware in the monolithic BIOS has been loaded or during loading of the monolithic BIOS in accordance with a predefined scheme.
Today's firmware architectures include provisions for extending BIOS functionality beyond that provided by the BIOS code stored in a platform's BIOS device (e.g., flash memory). More particularly, the Extensible Firmware Interface (EFI) (http://developer.intel.com/technology/efi) enables firmware, in the form of firmware modules and drivers, to be loaded from a variety of different resources, including primary and secondary flash devices, option ROMs, various persistent storage devices (e.g., hard disks, CD ROMs, etc.), and even over computer networks.
An issue of great concern for many computer vendors and users is code authenticity. While normally considered with respect to software, unauthentic firmware is also a concern. For example, unauthentic code may be flashed to a firmware storage device without the user's knowledge. The unauthentic code may comprise a virus or Trojan, causing malicious damage to the user's computer when launched. This problem is even more of a concern in a network environment, wherein the launch of a virus on one computer may cause the virus to infiltrate other computers on the network.
In many cases, vendors are averse to including authentication information, such as versioning data and the like. One reason is that conventional versioning requires overhead that is often at a premium. For example, a common way of including versioning data is to embed such data in a header of a corresponding binary file. This consumes space, and becomes even a bigger issue when considering its application to modular firmware environments such as EFI, wherein the system firmware may include 10's of different firmware binaries.
In other cases, the vendor has no choice when it comes to authentication. Existing firmware components, such as Option ROMs, have binary encodings that include pointers and other references to specific offsets (i.e., absolute address references). Thus, it is not possible to add new or additional header information, as this would cause the offsets to change, making the code inoperable.